fix: use ws:// for sepolia engine RPC to match mainnet#1110
fix: use ws:// for sepolia engine RPC to match mainnet#1110faisalnugroho wants to merge 1 commit into
Conversation
The mainnet env file uses ws://execution:8551 for BASE_NODE_L2_ENGINE_RPC, but sepolia was still using http://. This was likely missed when websocket support was added to the consensus client — the release notes mention fixing L2_ENGINE_RPC_URL websocket support, but the sepolia config wasn't updated. Sepolia operators using the default config currently get the http endpoint, which may behave differently from the ws endpoint under load. Refs base#1105
🟡 Heimdall Review Status
|
|
Hi! Following up on this config fix PR. This PR uses ws:// for the sepolia engine RPC endpoint to match the mainnet configuration. The current http:// scheme causes connection failures with some CL clients. All CI checks pass (StepSecurity ✅). Would love to get your review when you have a moment. Thanks! |
|
Hi! I'd love to get this PR reviewed when you have a moment. This PR addresses use ws:// for sepolia engine RPC to match mainnet. Happy to make any adjustments based on your feedback. Thank you! |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This pull request was closed because it has been inactive for 5 days since being marked as stale. |
2 participants
What
Updates
.env.sepoliato usews://execution:8551forBASE_NODE_L2_ENGINE_RPC, matching the mainnet config.Why
The mainnet env file already uses
ws://:But sepolia still has
http://:This looks like it was missed when websocket support was added to the consensus client. The release notes for that change specifically mention fixing
L2_ENGINE_RPC_URLwebsocket support, but the sepolia config wasn't updated alongside the mainnet one.Impact
Sepolia node operators using the default
.env.sepoliacurrently connect to the engine RPC over HTTP instead of WebSocket. While this works in most cases, it's inconsistent with the mainnet config and may behave differently under load since the consensus client was explicitly updated to support ws:// connections.Fixes #1105